home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc840.txt < prev    next >
Text File  |  1997-04-01  |  34KB  |  1,335 lines
  1.  
  2.  
  3. Network Working Group                                          J. Postel
  4. Request for Comments: 840                                            ISI
  5.                                                               April 1983
  6.  
  7.                            Official Protocols
  8.  
  9.  
  10. This RFC identifies the documents specifying the official protocols used
  11. in the Internet.  Annotations identify any revisions or changes planned.
  12.  
  13. To first order, the official protocols are those in the Internet
  14. Protocol Transition Workbook (IPTW) dated March 1982.  There are several
  15. protocols in use that are not in the IPTW.  A few of the protocols in
  16. the IPTW have been revised these are noted here.  In particular, the
  17. mail protocols have been revised and issued as a volume titled "Internet
  18. Mail Protocols" dated November 1982.  There is a volume of protocol
  19. related information called the Internet Protocol Implementers Guide
  20. (IPIG) dated August 1982.  A few of the protocols (in particular the
  21. Telnet Options) have not been revised for many years, these are found in
  22. the old ARPANET Protocol Handbook (APH) dated January 1978.
  23.  
  24. This document is organized as a sketchy outline.  The entries are
  25. protocols (e.g., Transmission Control Protocol).  In each entry there
  26. are notes on status, specification, comments, other references,
  27. dependencies, and contact.
  28.  
  29.    The status is one of: required, recommended, elective, or
  30.    experimental.
  31.  
  32.    The specification identifies the protocol defining documents.
  33.  
  34.    The comments describe any differences from the specification or
  35.    problems with the protocol.
  36.  
  37.    The other references identify documents that comment on or expand on
  38.    the protocol.
  39.  
  40.    The dependencies indicate what other protocols are called upon by
  41.    this protocol.
  42.  
  43.    The contact indicates a person who can answer questions about the
  44.    protocol.
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.  
  60. RFC 840                                                       April 1983
  61.                                                       Official Protocols
  62.  
  63.  
  64.    In particular, the status may need some further clarification:
  65.  
  66.       required
  67.  
  68.          - all hosts must implement the required protocol,
  69.  
  70.       recommended
  71.  
  72.          - all hosts are encouraged to implement the recommended
  73.          protocol,
  74.  
  75.       elective
  76.  
  77.          - hosts may implement or not the elective protocol,
  78.  
  79.       experimental
  80.  
  81.          - hosts should not implement the experimental protocol unless
  82.          they are participating in the experiment and have coordinated
  83.          their use of this protocol with the contact person, and
  84.  
  85.       none
  86.  
  87.          - this is not a protocol.
  88.  
  89. Overview
  90.  
  91.    Catenet Model
  92.  
  93.       STATUS:  None
  94.  
  95.       SPECIFICATION:  IEN 48 (in IPTW)
  96.  
  97.       COMMENTS:
  98.  
  99.          Gives an overview of the organization and principles of the
  100.          Internet.
  101.  
  102.          Could be revised and expanded.
  103.  
  104.       OTHER REFERENCES:
  105.  
  106.       DEPENDENCIES:
  107.  
  108.       CONTACT: Postel@USC-ISIF
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. Postel                                                          [Page 2]
  116.  
  117.  
  118. RFC 840                                                       April 1983
  119.                                                       Official Protocols
  120.  
  121.  
  122. Network Level
  123.  
  124.    Internet Protocol (IP)
  125.  
  126.       STATUS:  Required
  127.  
  128.       SPECIFICATION:  RFC 791 (in IPTW)
  129.  
  130.       COMMENTS:
  131.  
  132.          A few minor problems have been noted in this document.
  133.  
  134.          The most serious is a bit of confusion in the route options.
  135.          The route options have a pointer that indicates which octet of
  136.          the route is the next to be used.  The confusion is between the
  137.          phrases "the pointer is relative to this option" and "the
  138.          smallest legal value for the pointer is 4".  If you are
  139.          confused, forget about the relative part, the pointer begins
  140.          at 4.
  141.  
  142.          Another important point is the alternate reassembly procedure
  143.          suggested in RFC 815.
  144.  
  145.          Note that ICMP is defined to be an integral part of IP.  You
  146.          have not completed an implementation of IP if it does not
  147.          include ICMP.
  148.  
  149.       OTHER REFERENCES:
  150.  
  151.          RFC 815 (in IPIG) - IP Datagram Reassembly Algorithms
  152.  
  153.          RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
  154.  
  155.          RFC 816 (in IPIG) - Fault Isolation and Recovery
  156.  
  157.          RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
  158.          Implementation
  159.  
  160.       DEPENDENCIES:
  161.  
  162.       CONTACT: Postel@USC-ISIF
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.  
  176. RFC 840                                                       April 1983
  177.                                                       Official Protocols
  178.  
  179.  
  180.    Internet Control Message Protocol (ICMP)
  181.  
  182.       STATUS:  Required
  183.  
  184.       SPECIFICATION:  RFC 792 (in IPTW)
  185.  
  186.       COMMENTS:
  187.  
  188.          A few minor errors in the document have been noted.
  189.          Suggestions have been made for additional types of redirect
  190.          message and additional destination unreachable messages.
  191.  
  192.       OTHER REFERENCES:
  193.  
  194.       DEPENDENCIES: Internet Protocol
  195.  
  196.       CONTACT: Postel@USC-ISIF
  197.  
  198. Host Level
  199.  
  200.    User Datagram Protocol (UDP)
  201.  
  202.       STATUS:  Recommended
  203.  
  204.       SPECIFICATION:  RFC 768 (in IPTW)
  205.  
  206.       COMMENTS:
  207.  
  208.          The only change noted for the UDP specification is a minor
  209.          clarification that if in computing the checksum a padding octet
  210.          is used for the computation it is not transmitted or counted in
  211.          the length.
  212.  
  213.       OTHER REFERENCES:
  214.  
  215.       DEPENDENCIES: Internet Protocol
  216.  
  217.       CONTACT: Postel@USC-ISIF
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231. Postel                                                          [Page 4]
  232.  
  233.  
  234. RFC 840                                                       April 1983
  235.                                                       Official Protocols
  236.  
  237.  
  238.    Transmission Control Protocol (TCP)
  239.  
  240.       STATUS:  Recommended
  241.  
  242.       SPECIFICATION:  RFC 793 (in IPTW)
  243.  
  244.       COMMENTS:
  245.  
  246.          Many comments and corrections have been received for the TCP
  247.          specification document.  These are primarily document bugs
  248.          rather than protocol bugs.
  249.  
  250.          Event Processing Section:  There are many minor corrections and
  251.          clarifications needed in this section.
  252.  
  253.          Push:  There are still some phrases in the document that give a
  254.          "record mark" flavor to the push.  These should be further
  255.          clarified.  The push is not a record mark.
  256.  
  257.          Listening Servers:  Several comments have been received on
  258.          difficulties with contacting listening servers.  There should
  259.          be some discussion of implementation issues for servers, and
  260.          some notes on alternative models of system and process
  261.          organization for servers.
  262.  
  263.          Maximum Segment Size:  The maximum segment size option should
  264.          be generalized and clarified.  It can be used to either
  265.          increase or decrease the maximum segment size from the default.
  266.          The default should be established more clearly.  The default is
  267.          based on the default maximum Internet Datagram size which is
  268.          576 octets counting the IP and TCP headers.  The option counts
  269.          only the segment data.  For each of IP and TCP the minimum
  270.          header is 20 octets and the maximum header is 60 octets. So the
  271.          default maximum data segment is could be anywhere from 456 to
  272.          536 octets.  The current proposal is to set it at 536 data
  273.          octets.
  274.  
  275.          Idle Connections:  There have been questions about
  276.          automatically closing idle connections.  Idle connections are
  277.          ok, and should not be closed.  There are several cases where
  278.          idle connections arise, for example, in Telnet when a user is
  279.          thinking for a long time following a message from the server
  280.          computer before his next input.  There is no TCP "probe"
  281.          mechanism, and none is needed.
  282.  
  283.          Queued Receive Data on Closing:  There are several points where
  284.          it is not clear from the description what to do about data
  285.          received by the TCP but not yet passed to the user,
  286.          particularly when the connection is being closed.  In general,
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.  
  292. RFC 840                                                       April 1983
  293.                                                       Official Protocols
  294.  
  295.  
  296.          the data is to be kept to give to the user if he does a RECV
  297.          call.
  298.  
  299.          Out of Order Segments:  The description says that segments that
  300.          arrive out of order, that is, are not exactly the next segment
  301.          to be processed, may be kept on hand.  It should also point out
  302.          that there is a very large performance penalty for not doing
  303.          so.
  304.  
  305.          User Time Out:  This is the time out started on an open or send
  306.          call.  If this user time out occurs the user should be
  307.          notified, but the connection should not be closed or the TCB
  308.          deleted.  The user should explicitly ABORT the connection if he
  309.          wants to give up.
  310.  
  311.       OTHER REFERENCES:
  312.  
  313.          RFC 813 (in IPIG) - Window and Acknowledgement Strategy in TCP
  314.  
  315.          RFC 814 (in IPIG) - Names, Addresses, Ports, and Routes
  316.  
  317.          RFC 816 (in IPIG) - Fault Isolation and Recovery
  318.  
  319.          RFC 817 (in IPIG) - Modularity and Efficiency in Protocol
  320.          Implementation
  321.  
  322.       DEPENDENCIES: Internet Protocol
  323.  
  324.       CONTACT: Postel@USC-ISIF
  325.  
  326.    Host Monitoring Protocol (HMP)
  327.  
  328.       STATUS:  Elective
  329.  
  330.       SPECIFICATION:  IEN 197
  331.  
  332.       COMMENTS:
  333.  
  334.          This is a good tool for debuging protocol implementations in
  335.          small remotely located computers.
  336.  
  337.          This protocol is used to monitor Internet gateways and the
  338.          TACs.
  339.  
  340.       OTHER REFERENCES:
  341.  
  342.       DEPENDENCIES: Internet Protocol
  343.  
  344.       CONTACT: Hinden@BBN-UNIX
  345.  
  346.  
  347. Postel                                                          [Page 6]
  348.  
  349.  
  350. RFC 840                                                       April 1983
  351.                                                       Official Protocols
  352.  
  353.  
  354.    Cross Net Debugger (XNET)
  355.  
  356.       STATUS:  Elective
  357.  
  358.       SPECIFICATION:  IEN 158
  359.  
  360.       COMMENTS:
  361.  
  362.          This specification should be updated and reissued as an RFC.
  363.  
  364.       OTHER REFERENCES:
  365.  
  366.          RFC 643
  367.  
  368.       DEPENDENCIES: Internet Protocol
  369.  
  370.       CONTACT: Postel@USC-ISIF
  371.  
  372.    Exterior Gateway Protocol (EGP)
  373.  
  374.       STATUS:  Experimental
  375.  
  376.       SPECIFICATION:  RFC 827
  377.  
  378.       COMMENTS:
  379.  
  380.          Please discuss any plans for implementation or use of this
  381.          protocol with the contact.
  382.  
  383.       OTHER REFERENCES:
  384.  
  385.       DEPENDENCIES: Internet Protocol
  386.  
  387.       CONTACT: Postel@USC-ISIF
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405. Postel                                                          [Page 7]
  406.  
  407.  
  408. RFC 840                                                       April 1983
  409.                                                       Official Protocols
  410.  
  411.  
  412.    Gateway Gateway Protocol (GGP)
  413.  
  414.       STATUS:  Experimental
  415.  
  416.       SPECIFICATION:  RFC 823
  417.  
  418.       COMMENTS:
  419.  
  420.          Please discuss any plans for implementation or use of this
  421.          protocol with the contact.
  422.  
  423.       OTHER REFERENCES:
  424.  
  425.       DEPENDENCIES: Internet Protocol
  426.  
  427.       CONTACT: Brescia@BBN-UNIX
  428.  
  429.    Multiplexing Protocol
  430.  
  431.       STATUS:  Experimental
  432.  
  433.       SPECIFICATION:  IEN 90
  434.  
  435.       COMMENTS:
  436.  
  437.          No current experiment in progress.  There is some question as
  438.          to the extent to which the sharing this protocol envisions can
  439.          actually take place.  Also, there are some issues about the
  440.          information captured in the multiplexing header being (a)
  441.          insufficient, or (b) over specific.
  442.  
  443.          Please discuss any plans for implementation or use of this
  444.          protocol with the contact.
  445.  
  446.       OTHER REFERENCES:
  447.  
  448.       DEPENDENCIES: Internet Protocol
  449.  
  450.       CONTACT: Postel@USC-ISIF
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463. Postel                                                          [Page 8]
  464.  
  465.  
  466. RFC 840                                                       April 1983
  467.                                                       Official Protocols
  468.  
  469.  
  470.    Stream Protocol (ST)
  471.  
  472.       STATUS:  Experimental
  473.  
  474.       SPECIFICATION:  IEN 119
  475.  
  476.       COMMENTS:
  477.  
  478.          The implementation of this protocol has evolved and may no
  479.          longer be consistent with this specification.  The document
  480.          should be updated and issued as an RFC.
  481.  
  482.          Please discuss any plans for implementation or use of this
  483.          protocol with the contact.
  484.  
  485.       OTHER REFERENCES:
  486.  
  487.       DEPENDENCIES: Internet Protocol
  488.  
  489.       CONTACT: Forgie@BBN
  490.  
  491.    Network Voice Protocol (NVP-II)
  492.  
  493.       STATUS:  Experimental
  494.  
  495.       SPECIFICATION:  RFC xxx
  496.  
  497.       COMMENTS:
  498.  
  499.          The specification is an ISI Internal Memo which should be
  500.          updated and issued as an RFC.
  501.  
  502.          Please discuss any plans for implementation or use of this
  503.          protocol with the contact.
  504.  
  505.       OTHER REFERENCES:
  506.  
  507.       DEPENDENCIES: Internet Protocol, Stream Protocol
  508.  
  509.       CONTACT: Casner@USC-ISIB
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521. Postel                                                          [Page 9]
  522.  
  523.  
  524. RFC 840                                                       April 1983
  525.                                                       Official Protocols
  526.  
  527.  
  528. Application Level
  529.  
  530.    Telnet Protocol (TELNET)
  531.  
  532.       STATUS:  Recommended
  533.  
  534.       SPECIFICATION:  RFC 764 (in IPTW)
  535.  
  536.       COMMENTS:
  537.  
  538.          A few minor typographical errors should be corrected and some
  539.          clarification of the SYNCH mechanism should be made.
  540.  
  541.       OTHER REFERENCES:
  542.  
  543.       DEPENDENCIES: Transmission Control Protocol
  544.  
  545.       CONTACT: Postel@USC-ISIF
  546.  
  547.    Telnet Options (TELNET)
  548.  
  549.       Number   Name                                   RFC   NIC  APH USE
  550.       ------   ------------------------------------   ---  ----- --- ---
  551.          0     Binary Transmission                    ...  15389 yes yes
  552.          1     Echo                                   ...  15390 yes yes
  553.          2     Reconnection                           ...  15391 yes  no
  554.          3     Suppress Go Ahead                      ...  15392 yes yes
  555.          4     Approximate Message Size Negotiation   ...  15393 yes  no
  556.          5     Status                                 651  31154 yes yes
  557.          6     Timing Mark                            ...  16238 yes yes
  558.          7     Remote Controlled Trans and Echo       726  39237 yes  no
  559.          8     Output Line Width                      ...  20196 yes  no
  560.          9     Output Page Size                       ...  20197 yes  no
  561.         10     Output Carriage-Return Disposition     652  31155 yes  no
  562.         11     Output Horizontal Tabstops             653  31156 yes  no
  563.         12     Output Horizontal Tab Disposition      654  31157 yes  no
  564.         13     Output Formfeed Disposition            655  31158 yes  no
  565.         14     Output Vertical Tabstops               656  31159 yes  no
  566.         15     Output Vertical Tab Disposition        657  31160 yes  no
  567.         16     Output Linefeed Disposition            658  31161 yes  no
  568.         17     Extended ASCII                         698  32964 yes  no
  569.         18     Logout                                 727  40025 yes  no
  570.         19     Byte Macro                             735  42083 yes  no
  571.         20     Data Entry Terminal                    732  41762 yes  no
  572.         21     SUPDUP                             734 736  42213 yes  no
  573.         22     SUPDUP Output                          749  45449  no  no
  574.         23     Send Location                          779  -----  no  no
  575.        255     Extended-Options-List                  ...  16239 yes yes
  576.  
  577.  
  578.  
  579. Postel                                                         [Page 10]
  580.  
  581.  
  582. RFC 840                                                       April 1983
  583.                                                       Official Protocols
  584.  
  585.  
  586.       STATUS:  Elective
  587.  
  588.       SPECIFICATION:  (in APH)
  589.  
  590.       COMMENTS:
  591.  
  592.          There is an open question about some of these.  Most of the
  593.          options are implemented by so few hosts that perhaps they
  594.          should be eliminated.  These should all be studied and the
  595.          useful ones reissued as RFCs.
  596.  
  597.          The last column (USE) of the table above indicates which
  598.          options are in general use.
  599.  
  600.          The following are recommended:  Binary Transmission, Echo,
  601.          Suppress Go Ahead, Status, Timing Mark, and Extended Options
  602.          List.
  603.  
  604.          Many of these must be revised for use with TCP.
  605.  
  606.       OTHER REFERENCES:
  607.  
  608.       DEPENDENCIES: Telnet
  609.  
  610.       CONTACT: Postel@USC-ISIF
  611.  
  612.    File Transfer Protocol (FTP)
  613.  
  614.       STATUS:  Recommended
  615.  
  616.       SPECIFICATION:  RFC 765 (in IPTW)
  617.  
  618.       COMMENTS:
  619.  
  620.          There are a number of minor corrections to be made.  A major
  621.          change is the deletion of the mail commands, and a major
  622.          clarification is needed in the discussion of the management of
  623.          the data connection.  Also, a suggestion has been made to
  624.          include some directory manipulation commands (RFC 775).
  625.  
  626.          Eventhough the MAIL features are defined in this document, they
  627.          are not to be used.  The SMTP protocol is to be used for all
  628.          mail service in the Internet.
  629.  
  630.          Data Connection Management:
  631.  
  632.             a.  Default Data Connection Ports:  All FTP implementations
  633.             must support use of the default data connection ports, and
  634.             only the User-PI may initiate the use of non-default ports.
  635.  
  636.  
  637. Postel                                                         [Page 11]
  638.  
  639.  
  640. RFC 840                                                       April 1983
  641.                                                       Official Protocols
  642.  
  643.  
  644.             b.  Negotiating Non-Default Data Ports:   The User-PI may
  645.             specify a non-default user side data port with the PORT
  646.             command.  The User-PI may request the server side to
  647.             identify a non-default server side data port with the PASV
  648.             command.  Since a connection is defined by the pair of
  649.             addresses, either of these actions is enough to get a
  650.             different data connection, still it is permitted to do both
  651.             commands to use new ports on both ends of the data
  652.             connection.
  653.  
  654.             c.  Reuse of the Data Connection:  When using the stream
  655.             mode of data transfer the end of the file must be indicated
  656.             by closing the connection.  This causes a problem if
  657.             multiple files are to be transfered in the session, due to
  658.             need for TCP to hold the connection record for a time out
  659.             period to guarantee the reliable communication.  Thus the
  660.             connection can not be reopened at once.
  661.  
  662.                There are two solutions to this problem.  The first is to
  663.                negotiate a non-default port (as in (b) above).  The
  664.                second is to use another transfer mode.
  665.  
  666.                A comment on transfer modes.  The stream transfer mode is
  667.                inherently unreliable, since one can not determine if the
  668.                connection closed prematurely or not.  The other transfer
  669.                modes (Block, Compressed) do not close the connection to
  670.                indicate the end of file.  They have enough FTP encoding
  671.                that the data connection can be parsed to determine the
  672.                end of the file.  Thus using these modes one can leave
  673.                the data connection open for multiple file transfers.
  674.  
  675.                Why this was not a problem with the old NCP FTP:
  676.  
  677.                   The NCP was designed with only the ARPANET in mind.
  678.                   The ARPANET provides very reliable service, and the
  679.                   NCP counted on it.  If any packet of data from an NCP
  680.                   connection were lost or damaged by the network the NCP
  681.                   could not recover.  It is a tribute to the ARPANET
  682.                   designers that the NCP FTP worked so well.
  683.  
  684.                   The TCP is designed to provide reliable connections
  685.                   over many different types of networks and
  686.                   interconnections of networks.  TCP must cope with a
  687.                   set of networks that can not promise to work as well
  688.                   as the ARPANET.  TCP must make its own provisions for
  689.                   end-to-end recovery from lost or damaged packets.
  690.                   This leads to the need for the connection phase-down
  691.                   time-out.  The NCP never had to deal with
  692.                   acknowledgements or retransmissions or many other
  693.  
  694.  
  695. Postel                                                         [Page 12]
  696.  
  697.  
  698. RFC 840                                                       April 1983
  699.                                                       Official Protocols
  700.  
  701.  
  702.                   things the TCP must do to make connection reliable in
  703.                   a more complex world.
  704.  
  705.          LIST and NLST:
  706.  
  707.             There is some confusion about the LIST an NLST commands, and
  708.             what is appropriate to return.  Some clarification and
  709.             motivation for these commands should be added to the
  710.             specification.
  711.  
  712.       OTHER REFERENCES:
  713.  
  714.          RFC 678 - Document File Format Standards
  715.  
  716.       DEPENDENCIES: Transmission Control Protocol
  717.  
  718.       CONTACT: Postel@USC-ISIF
  719.  
  720.    Trivial File Transfer Protocol (TFTP)
  721.  
  722.       STATUS:  Elective
  723.  
  724.       SPECIFICATION:  RFC 783 (in IPTW)
  725.  
  726.       COMMENTS:
  727.  
  728.          No known problems with this specification.  This is in use in
  729.          several local networks.
  730.  
  731.       OTHER REFERENCES:
  732.  
  733.       DEPENDENCIES: User Datagram Protocol
  734.  
  735.       CONTACT: Postel@USC-ISIF
  736.  
  737.    Simple Mail Transfer Protocol (SMTP)
  738.  
  739.       STATUS:  Recommended
  740.  
  741.       SPECIFICATION:  RFC 821
  742.  
  743.       COMMENTS:
  744.  
  745.          This has been revised since the IPTW, it is in the "Internet
  746.          Mail Protocols" volume of November 1982.  RFC 788 (in IPTW) is
  747.          obsolete.
  748.  
  749.          There have been many misunderstandings and errors in the early
  750.  
  751.  
  752.  
  753. Postel                                                         [Page 13]
  754.  
  755.  
  756. RFC 840                                                       April 1983
  757.                                                       Official Protocols
  758.  
  759.  
  760.          implementations.  Some documentation of these problems can be
  761.          found in the file [ISIF]<SMTP>MAIL.ERRORS.
  762.  
  763.          Some minor differences between RFC 821 and RFC 822 should be
  764.          resolved.
  765.  
  766.       OTHER REFERENCES:
  767.  
  768.          RFC 822 - Mail Header Format Standards
  769.  
  770.             This has been revised since the IPTW, it is in the "Internet
  771.             Mail Protocols" volume of November 1982.  RFC 733 (in IPTW)
  772.             is obsolete.  Further revision of RFC 822 is needed to
  773.             correct some minor errors in the details of the
  774.             specification.
  775.  
  776.       DEPENDENCIES: Transmission Control Protocol
  777.  
  778.       CONTACT: Postel@USC-ISIF
  779.  
  780.    Remote Job Entry (RJE)
  781.  
  782.       STATUS:  Elective
  783.  
  784.       SPECIFICATION:  RFC 407 (in APH)
  785.  
  786.       COMMENTS:
  787.  
  788.          Some changes needed for use with TCP.
  789.  
  790.          No known active implementations.
  791.  
  792.       OTHER REFERENCES:
  793.  
  794.       DEPENDENCIES: File Transfer Protocol
  795.                     Transmission Control Protocol
  796.  
  797.       CONTACT: Postel@USC-ISIF
  798.  
  799.  
  800.  
  801.  
  802.  
  803.  
  804.  
  805.  
  806.  
  807.  
  808.  
  809.  
  810.  
  811. Postel                                                         [Page 14]
  812.  
  813.  
  814. RFC 840                                                       April 1983
  815.                                                       Official Protocols
  816.  
  817.  
  818.    Remote Job Service (NETRJS)
  819.  
  820.       STATUS:  Elective
  821.  
  822.       SPECIFICATION:  RFC 740 (in APH)
  823.  
  824.       COMMENTS:
  825.  
  826.          Used with the UCLA IBM OS system.
  827.  
  828.          Please discuss any plans for implementation or use of this
  829.          protocol with the contact.
  830.  
  831.          Revision in progress.
  832.  
  833.       OTHER REFERENCES:
  834.  
  835.       DEPENDENCIES: Transmission Control Protocol
  836.  
  837.       CONTACT: Braden@USC-ISIA
  838.  
  839.    Remote Telnet Service
  840.  
  841.       STATUS:  Elective
  842.  
  843.       SPECIFICATION:  RFC 818
  844.  
  845.       COMMENTS:
  846.  
  847.       OTHER REFERENCES:
  848.  
  849.       DEPENDENCIES: Telnet, Transmission Control Protocol
  850.  
  851.       CONTACT: Postel@USC-ISIF
  852.  
  853.    Graphics Protocol
  854.  
  855.       STATUS:  Elective
  856.  
  857.       SPECIFICATION:  NIC 24308 (in APH)
  858.  
  859.       COMMENTS:
  860.  
  861.          Very minor changes needed for use with TCP.
  862.  
  863.          No known active implementations.
  864.  
  865.       OTHER REFERENCES:
  866.  
  867.  
  868.  
  869. Postel                                                         [Page 15]
  870.  
  871.  
  872. RFC 840                                                       April 1983
  873.                                                       Official Protocols
  874.  
  875.  
  876.       DEPENDENCIES: Telnet, Transmission Control Protocol
  877.  
  878.       CONTACT: Postel@USC-ISIF
  879.  
  880.    Echo Protocol
  881.  
  882.       STATUS:  Recommended
  883.  
  884.       SPECIFICATION:  RFC 347
  885.  
  886.       COMMENTS:
  887.  
  888.          This specification should be revised for use with TCP and
  889.          reissued.
  890.  
  891.       OTHER REFERENCES:
  892.  
  893.       DEPENDENCIES: Transmission Control Protocol
  894.                     or User Datagram Protocol
  895.  
  896.       CONTACT: Postel@USC-ISIF
  897.  
  898.    Discard Protocol
  899.  
  900.       STATUS:  Elective
  901.  
  902.       SPECIFICATION:  RFC 348
  903.  
  904.       COMMENTS:
  905.  
  906.          This specification should be revised for use with TCP and
  907.          reissued.
  908.  
  909.       OTHER REFERENCES:
  910.  
  911.       DEPENDENCIES: Transmission Control Protocol
  912.                     or User Datagram Protocol
  913.  
  914.       CONTACT: Postel@USC-ISIF
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927. Postel                                                         [Page 16]
  928.  
  929.  
  930. RFC 840                                                       April 1983
  931.                                                       Official Protocols
  932.  
  933.  
  934.    Character Generator Protocol
  935.  
  936.       STATUS:  Elective
  937.  
  938.       SPECIFICATION:  RFC 429
  939.  
  940.       COMMENTS:
  941.  
  942.          This specification should be revised for use with TCP and
  943.          reissued.
  944.  
  945.       OTHER REFERENCES:
  946.  
  947.       DEPENDENCIES: Transmission Control Protocol
  948.                     or User Datagram Protocol
  949.  
  950.       CONTACT: Postel@USC-ISIF
  951.  
  952.    Quote of the Day Protocol
  953.  
  954.       STATUS:  Elective
  955.  
  956.       SPECIFICATION:  RFC xxx
  957.  
  958.       COMMENTS:
  959.  
  960.          Open a connection to this server, it sends you a quote (as a
  961.          character string), and closes the connection.  This should be
  962.          described in an RFC.
  963.  
  964.       OTHER REFERENCES:
  965.  
  966.       DEPENDENCIES: Transmission Control Protocol
  967.                     or User Datagram Protocol
  968.  
  969.       CONTACT: Postel@USC-ISIF
  970.  
  971.    Active Users Protocol
  972.  
  973.       STATUS:  Elective
  974.  
  975.       SPECIFICATION:  RFC xxx
  976.  
  977.       COMMENTS:
  978.  
  979.          Open a connection to this server, it sends you a list of the
  980.          currently logged in users (as a character string), and closes
  981.          the connection.  This should be described in an RFC.
  982.  
  983.  
  984.  
  985. Postel                                                         [Page 17]
  986.  
  987.  
  988. RFC 840                                                       April 1983
  989.                                                       Official Protocols
  990.  
  991.  
  992.       OTHER REFERENCES:
  993.  
  994.       DEPENDENCIES: Transmission Control Protocol
  995.                     or User Datagram Protocol
  996.  
  997.       CONTACT: Postel@USC-ISIF
  998.  
  999.    Finger Protocol
  1000.  
  1001.       STATUS:  Elective
  1002.  
  1003.       SPECIFICATION:  RFC 742 (in APH)
  1004.  
  1005.       COMMENTS:
  1006.  
  1007.          Some extensions have been suggested.
  1008.  
  1009.          Some changes are are needed for TCP.
  1010.  
  1011.       OTHER REFERENCES:
  1012.  
  1013.       DEPENDENCIES: Transmission Control Protocol
  1014.  
  1015.       CONTACT: Postel@USC-ISIF
  1016.  
  1017.    NICNAME Protocol
  1018.  
  1019.       STATUS:  Elective
  1020.  
  1021.       SPECIFICATION:  RFC 812 (in IPTW)
  1022.  
  1023.       COMMENTS:
  1024.  
  1025.          Accesses the ARPANET Directory database.
  1026.  
  1027.       OTHER REFERENCES:
  1028.  
  1029.       DEPENDENCIES: Transmission Control Protocol
  1030.  
  1031.       CONTACT: Feinler@SRI-NIC
  1032.  
  1033.  
  1034.  
  1035.  
  1036.  
  1037.  
  1038.  
  1039.  
  1040.  
  1041.  
  1042.  
  1043. Postel                                                         [Page 18]
  1044.  
  1045.  
  1046. RFC 840                                                       April 1983
  1047.                                                       Official Protocols
  1048.  
  1049.  
  1050.    HOSTNAME Protocol
  1051.  
  1052.       STATUS:  Elective
  1053.  
  1054.       SPECIFICATION:  RFC 811 (in IPTW)
  1055.  
  1056.       COMMENTS:
  1057.  
  1058.          Accesses the Registered Internet Hosts database (HOSTS.TXT).
  1059.  
  1060.       OTHER REFERENCES:
  1061.  
  1062.          RFC 810 - Host Table Specification
  1063.  
  1064.       DEPENDENCIES: Transmission Control Protocol
  1065.  
  1066.       CONTACT: Feinler@SRI-NIC
  1067.  
  1068.    Host Name Server Protocol
  1069.  
  1070.       STATUS:  Experimental
  1071.  
  1072.       SPECIFICATION:  IEN 116 (in IPTW)
  1073.  
  1074.       COMMENTS:
  1075.  
  1076.          This specification has significant problems:  1) The name
  1077.          syntax is out of date.  2) The protocol details are ambiguous,
  1078.          in particular, the length octet either does or doesn't include
  1079.          itself and the op code.  3) The extensions are not supported by
  1080.          any known implementation.
  1081.  
  1082.          Work is in progress on a significant revision.  Further
  1083.          implementations of this protocol are not advised.
  1084.  
  1085.          Please discuss any plans for implementation or use of this
  1086.          protocol with the contact.
  1087.  
  1088.       OTHER REFERENCES:
  1089.  
  1090.       DEPENDENCIES: User Datagram Protocol
  1091.  
  1092.       CONTACT: Postel@USC-ISIF
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101. Postel                                                         [Page 19]
  1102.  
  1103.  
  1104. RFC 840                                                       April 1983
  1105.                                                       Official Protocols
  1106.  
  1107.  
  1108.    CSNET Mailbox Name Server Protocol
  1109.  
  1110.       STATUS:  Experimental
  1111.  
  1112.       SPECIFICATION:  CS-DN-2
  1113.  
  1114.       COMMENTS:
  1115.  
  1116.          Please discuss any plans for implementation or use of this
  1117.          protocol with the contact.
  1118.  
  1119.       OTHER REFERENCES:
  1120.  
  1121.       DEPENDENCIES: Transmission Control Protocol
  1122.  
  1123.       CONTACT: Solomon@UWISC
  1124.  
  1125.    Daytime Protocol
  1126.  
  1127.       STATUS:  Elective
  1128.  
  1129.       SPECIFICATION:  RFC xxx
  1130.  
  1131.       COMMENTS:
  1132.  
  1133.          Open a connection to this server, it sends you the date and
  1134.          time (as a character string), and closes the connection.  This
  1135.          should be described in an RFC.
  1136.  
  1137.       OTHER REFERENCES:
  1138.  
  1139.       DEPENDENCIES: Transmission Control Protocol
  1140.                     or User Datagram Protocol
  1141.  
  1142.       CONTACT: Postel@USC-ISIF
  1143.  
  1144.    Time Server Protocol
  1145.  
  1146.       STATUS:  Recommended
  1147.  
  1148.       SPECIFICATION:  IEN 142
  1149.  
  1150.       COMMENTS:
  1151.  
  1152.          Open a connection to this server, it sends you the date and
  1153.          time (as a 32-bit number), and closes the connection.  Or send
  1154.          a user datagram and it send back a datagram containing the date
  1155.          and time (as a 32-bit number).
  1156.  
  1157.  
  1158.  
  1159. Postel                                                         [Page 20]
  1160.  
  1161.  
  1162. RFC 840                                                       April 1983
  1163.                                                       Official Protocols
  1164.  
  1165.  
  1166.          No known problems.  Specification should be reissued as an RFC.
  1167.  
  1168.       OTHER REFERENCES:
  1169.  
  1170.       DEPENDENCIES: Transmission Control Protocol
  1171.                     or User Datagram Protocol
  1172.  
  1173.       CONTACT: Postel@USC-ISIF
  1174.  
  1175.    DCNET Time Server Protocol (Internet Clock Service)
  1176.  
  1177.       STATUS:  Elective
  1178.  
  1179.       SPECIFICATION:  RFC 778
  1180.  
  1181.       COMMENTS:
  1182.  
  1183.       OTHER REFERENCES:
  1184.  
  1185.       DEPENDENCIES: Internet Control Message Protocol
  1186.  
  1187.       CONTACT: Mills@LINKABIT-DCN6
  1188.  
  1189.    SUPDUP Protocol
  1190.  
  1191.       STATUS:  Elective
  1192.  
  1193.       SPECIFICATION:  RFC 734 (in APH)
  1194.  
  1195.       COMMENTS:
  1196.  
  1197.       OTHER REFERENCES:
  1198.  
  1199.       DEPENDENCIES: Transmission Control Protocol
  1200.  
  1201.       CONTACT: Admin.MRC@SU-SCORE
  1202.  
  1203.    Internet Message Protocol (MPM)
  1204.  
  1205.       STATUS:  Experimental
  1206.  
  1207.       SPECIFICATION:  RFC 753
  1208.  
  1209.       COMMENTS:
  1210.  
  1211.          This is an experimental multimedia mail transfer protocol.  The
  1212.          implementation is called a Message Processing Module or MPM.
  1213.  
  1214.  
  1215.  
  1216.  
  1217. Postel                                                         [Page 21]
  1218.  
  1219.  
  1220. RFC 840                                                       April 1983
  1221.                                                       Official Protocols
  1222.  
  1223.  
  1224.          Please discuss any plans for implementation or use of this
  1225.          protocol with the contact.
  1226.  
  1227.       OTHER REFERENCES:
  1228.  
  1229.          RFC 767 - Structured Document Formats
  1230.  
  1231.       DEPENDENCIES: Transmission Control Protocol
  1232.  
  1233.       CONTACT: Postel@USC-ISIF
  1234.  
  1235. Appendices
  1236.  
  1237.    Assigned Numbers
  1238.  
  1239.       STATUS:  None
  1240.  
  1241.       SPECIFICATION:  RFC 820
  1242.  
  1243.       COMMENTS:
  1244.  
  1245.          Describes the fields of various protocols that are assigned
  1246.          specific values for actual use, and lists the currently
  1247.          assigned values.
  1248.  
  1249.          Issued January 1983, replaces RFC 790 in IPTW.
  1250.  
  1251.       OTHER REFERENCES:
  1252.  
  1253.       CONTACT: Postel@USC-ISIF
  1254.  
  1255.    Pre-emption
  1256.  
  1257.       STATUS:  Elective
  1258.  
  1259.       SPECIFICATION:  RFC 794 (in IPTW)
  1260.  
  1261.       COMMENTS:
  1262.  
  1263.          Describes how to do pre-emption of TCP connections.
  1264.  
  1265.       OTHER REFERENCES:
  1266.  
  1267.       CONTACT: Postel@USC-ISIF
  1268.  
  1269.  
  1270.  
  1271.  
  1272.  
  1273.  
  1274.  
  1275. Postel                                                         [Page 22]
  1276.  
  1277.  
  1278. RFC 840                                                       April 1983
  1279.                                                       Official Protocols
  1280.  
  1281.  
  1282.    Service Mappings
  1283.  
  1284.       STATUS:  None
  1285.  
  1286.       SPECIFICATION:  RFC 795 (in IPTW)
  1287.  
  1288.       COMMENTS:
  1289.  
  1290.          Describes the mapping of the IP type of service field onto the
  1291.          parameters of some specific networks.
  1292.  
  1293.          Out of date, needs revision.
  1294.  
  1295.       OTHER REFERENCES:
  1296.  
  1297.       CONTACT: Postel@USC-ISIF
  1298.  
  1299.    Address Mappings
  1300.  
  1301.       STATUS:  None
  1302.  
  1303.       SPECIFICATION:  RFC 796 (in IPTW)
  1304.  
  1305.       COMMENTS:
  1306.  
  1307.          Describes the mapping of the IP address field onto the address
  1308.          field of some specific networks.
  1309.  
  1310.          Out of date, needs revision.
  1311.  
  1312.       OTHER REFERENCES:
  1313.  
  1314.       CONTACT: Postel@USC-ISIF
  1315.  
  1316.  
  1317.  
  1318.  
  1319.  
  1320.  
  1321.  
  1322.  
  1323.  
  1324.  
  1325.  
  1326.  
  1327.  
  1328.  
  1329.  
  1330.  
  1331.  
  1332.  
  1333. Postel                                                         [Page 23]
  1334.  
  1335.